Verify that simple meetings can be passed back and forth regardless of what time zone setting is in place on either side.

Make sure the current time zone on the server and the device matches.

From the server, create a meeting that starts at 10am.

Perform a synchronization

Change the time zone on the device to a different time zone 3 hours later.

Create a new meeting starting at 10am from the server.

Perform a synchronization

Change the time zone of the server to match the new time zone.

Modify the title of one of the meetings.

Perform a synchronization

Repeat tests starting with device and server in opposite time zones.

Repeat tests with the server side meetings being created by another person inviting the owner of the mobile device where by the organizer is in a completely different time zone then those being used in the test.

The meeting should first display on the device at the correct time, 10am.

After changing time zones, the device should automatically change the times for all entries. The first meeting should now be displayed at 7am on the device.

After creating the second meeting and synchronizing, the server is still on the old time zone, so the times will differ. On the device, the first meeting is at 7am and the second at 10am, but on the server, the first meeting is at 10am, and the second at 1pm.

After changing the time zone on the server and making modifications, both the device and server should display the first meeting at 7am and the second meeting at 10am.

When tests are repeated the appropriate offsets should be seen but everything should still be where it is intended.

Verify that repeating meetings can be passed back and forth regardless of what time zone setting is in place on either side.

Make sure the current time zone on the server and the device matches.

From the server, create a repeating weekly meeting that starts at 10am.

Perform a synchronization

Change the time zone on the device to a different time zone 3 hours later.

Create a new repeating weekly meeting starting at 10am from the server.

Perform a synchronization

Change the time zone of the server to match the new time zone.

Modify the title of one of the meetings.

Perform a synchronization

Repeat tests starting with device and server in opposite time zones.

Repeat tests with the server side meetings being created by another person inviting the owner of the mobile device where by the organizer is in a completely different time zone then those being used in the test.

The meetings should first display on the device at the correct time, 10am.

After changing time zones, the device should automatically change the times for all entries. The meetings should now be displayed at 7am on the device.

After creating the second meeting and synchronizing, the server is still on the old time zone, so the times will differ. On the device, the first meetings are at 7am and the second ones at 10am, but on the server, they are at 10am and at 1pm respectively.

After changing the time zone on the server and making modifications, both the device and server should display the first set of meetings at 7am and the second set of meetings at 10am.

When tests are repeated the appropriate offsets should be seen but everything should still be where it is intended.

Verify that day events can be passed back and forth regardless of what time zone setting is in place on either side.

Make sure the current time zone on the server and the device matches.

From the server, create a Day Event filling out all fields.

Perform a synchronization

Change the time zone on the device to a different time zone 3 hours earlier.

Modify the title of the Day Event from the device.

Perform a synchronization

Change the time zone of the server to match the new time zone.

Modify the title of the Day Event from the server.

Perform a synchronization

Repeat tests starting with device and server in opposite time zones.

Repeat tests with the server side meetings being created by another person inviting the owner of the mobile device where by the organizer is in a completely different time zone then those being used in the test.

The Day Event should first display on the device. The Day Event should be displayed on the correct day on the device.

After changing the time zone on the device, the device should automatically change the times for all the entries. After modifying and syncing, the Day Event, the Day Event should still be displayed on the same date with the new title on both server and device.

After changing the time zone on the server, the Day Event should still be displayed on the same day with the new title on the device.

Day Events are independent of time zone changes.

When tests are repeated Day Events should continue to be seen as independent of differing time zones.

Verify that entries originating form the server before and after a switch remain displayed correctly to users.

Make sure you modify the synchronization range to include the daylight savings period you are about to test.

From the Server, create a single entry before and another single entry after the Spring daylight savings date at 10am, with all fields filled out.

Perform a synchronization

Push the time on the server and the device ahead to simulate crossing into daylight savings.

Create a new meeting server side at 10am

Perform a synchronization

Repeat tests with the server side meetings being created by another person inviting the owner of the mobile device where by the organizer is in a completely different time zone then those being used in the test which has a different date for DST changes.

The two entries should display on the device with all fields correctly mapped.

The time of the two entries should be at 10am.

After the time change the time of the two original entries and the new entry should still be at 10am

When tests are repeated meetings between when the organizer’s Time zone switch to DST and when the invitee’s Time zone switches should be offset by an hour (e.g. A 10am London meeting will normally be a 5am Montreal meeting but it will be at 6am after the province of Quebec switches to DST up until the point where British Summer Time kicks in at which point it will go back to being at 5am).

Verify that repeating entries originating form the server before and after a switch remain displayed correctly to users.

Make sure you modify the synchronization range to include the daylight savings period you are about to test.

From the Server, create a repeating daily entry that starts at 10am, with all fields filled out, which spans across a Spring daylight savings date

Perform a synchronization

Repeat tests with the server side meetings being created by another person inviting the owner of the mobile device where by the organizer is in a completely different time zone then those being used in the test which has a different date for DST changes.

All instances of the repeating entry should display on the device.

The times of ALL instances before and after the daylight savings date should be 10am.

When tests are repeated meetings between when the organizer’s Time zone switch to DST and when the invitee’s Time zone switches should be offset by an hour (e.g. A 10am London meeting will normally be a 5am Montreal meeting but it will be at 6am after the province of Quebec switches to DST up until the point where British Summer Time kicks in at which point it will go back to being at 5am).

Verify that entries originating for the device before and after a switch remain displayed correctly to users.

Make sure you modify the synchronization range to include the daylight savings period you are about to test.

From the device, create a single entry before and another single entry after the Autumn daylight savings date at 10am, with all fields filled out.

Perform a synchronization

Push the time on the server and the device ahead to simulate crossing into daylight savings.

Create a new meeting device side at 10am

Perform a synchronization

The two entries should display on the server with all fields correctly mapped.

The time of the two entries should be at 10am.

After the time change the time of the two original entries and the new entry should still be at 10am

Verify that repeating entries originating form the device before and after a switch remain displayed correctly to users.

Make sure you modify the synchronization range to include the daylight savings period you are about to test.

From the device, create a repeating daily entry that starts at 10am, with all fields filled out, which spans across an Autumn daylight savings date.

Perform a synchronization

All instances of the repeating entry should display on the Server.

The times of ALL instances before and after the daylight savings date should be 10am